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The Text Editor as A Uniform ^'a^/vachi^® Interface 
A Proposal for a Standard Editor 

t)y 

Lyle *shton Cox Jr. 

Department of Computer Science 
Naval Postgraduate Sf'hooi 
f^onter®y, California 

ABSTRACT 

There is a substantial group of professionals, S'^i<^nt i st s , 
engineers, and managers who ere justifiably reluctant to use 
computer networks such as the ARPANET, ^h i s phenomenon contirues 
despite the fact that they recognize some of the benefits of 
computational assistance, that they ha’-e had experi<=nce using 
computer systems, and that they have access to such a network. 
Their reluctance usually stems from the feeli’-g that the very 
great effort required to familiarize themis^^lves with new 
machines end systems is not justified by t'^e occasional or 
intermittent nature of their computational prohl‘=ms. In learning 
to use a new system, a large part of the f amil ia ri ze 1 1 on effort 
is spent in trying to learn to use a new t“xt editing program. 
If such a utility program were standardized end made available 
oo all of the ■machines on the networ'^-, a larg'^ obsta''l“ to the 
“fficient use of such systems mig^'t be re''cv‘=>d. Th® desigr of 
such a system, a Standard Line EDitor called ”SIED" is proposed 
h»re . 
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BACKGROUND 



The United States Navy is currently conducting an 
eiperirrent to determine the effectiveness of ccrputer retworkin^^ 
in providing; the computing support required by the Navy 
laboratories. In the course of this experiment, significant 
resources of the laboratories are bein^ orgranized into a "i\Avy 
Laboratory Computer Network" or "NALCON" (1' (2) to promote the 
efficient use of the physical and logical resources of the Navy 
laboratories. 

While the NALCON system was being implemented, it was 
recognized that software technology often poses greater problems 
than does the hardware design and construction. In response to 
this, the Navy Laboratory Computer Committee (NLCC) formed a 
Software Technology Working Group. It is the goal of this group 
to address the specific software problems of NALCON, end to 
consider t>ie larger problens of software technology in the Navy 
computing community. 

After a series of meetings, the Software Technology Working 
Group reported (5) that the number and diverse nature of text 
editor programs constituted a significant obstacle (both real 
ard psychologl cal ) to the efficient use of network resources. It 
was suggested that either a standard editor be developed, or 
that all network computers contain editors with a standard 
subset of commands. 
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Subsequently, work was undertaken at the Naval PostP:radu^< te 
School to determine the desirable character! sties whicn such an 
editor should display, and to define or specify the user 
interface for this proposed standard editor. Th“ results of* this 
effort are described below. 



PHILOSOPHY 

Before we describe the proposed standard editor, it is 
appropriate that several non-techn ical , philosophical, aspects 
of the editor design be discussed. 

It should be reco<?nized that any editor will certain some 
characteristics which significant portions of the corrutPr user 
community will find objectionable. The implemertat i on cf text 
editor features is often a matter of personal ta<^te. ''ou ^'an not 
please all of the people all of the time. Ve believe that the 
proposed editor is well thought out, and is based upon the 
experience of thousands of computer users spanri’^g well over a 
decade cf network and timesharing experience. Our scluticn is 
certainly not unique. There are other solutions. Ive have 
confidence that ours is one of the better possibilities, and 
should seriously be considered as a standard. 

With regards to the specif icati on itself, in th® following 
sections we will attempt to describe the editor i’^formally, 
using a mixture of two technicues. The description’ will not be a 
rigorous specification in the software engineering sense; nor 
will it be a "users view" of the editor. By ^orrbiring aspe-^ts of 
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these two techniques - specifications and a "users introduction" 
type description of the editor - we hope to both describe the 
editor in sufficient detail that it can be i eren ted , and giv® 
the readers a "feel" for using the editor. V.e as^ that the 
reader keep in mind the goal of the standard editor project, and 
this philosophy while reading the remainder of this paper. 

TEE GOALS OF A "STANDARD EDITOR" 

The goal of the Standard Editor project is to define and 
develop a simple and easy to use text editor program which can 
be readily implemented on a wide variety of host ma^'hines end 
operating systems. This objective and the computer network 
context of its development allow further definition of SIED 
requirements . 

The usage envisioned for SIED is twofold? casual use by 
persons local to the host; and use by occasional network guests 
of the host. Such a simple, basic editor can not and should not 
attempt to replace the princip<=>l system »ditor programs 
available on the host machines. Since the scope of usage is thus 
reduced, no attempt need be made to design SLFD to be all 
powerful (and hence complex). SLED only needs to support tne 
basic text editing functions, and if these functions are 
supported In a well designed, well documented, easy to use 
implementation, the basic goals of the project can be fulfilled. 

The limited scope also allows implementaticns to be 
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accomplished without undue attention to questions of ex^cuticn 
efficiency which are vital in the design of a principal system 
editor. Thus implementations can he realized usinp higher level 
computer programming languages, with emphasis on portability and 
system independence. 

The wide variety of users anticipated, and the large number 
of implemen tations, requires several oheracteristics of th^ 
editor to be present in all its Implementations. Certainly all 
the implementations must be as nearly uniform (in terms of the 
user Interface) as current software technology permits. In 
designing the editor, the usage and commands must be kept 
simple. The commands must function "intuitively" and be easy to 
learn and remember. Further, no special terminal character set 
or line speed assumptions can be made. 

SPECIFYING THE EDITOR 

From these general requirements, a "~ore detailed 
specification was developed. Great effort was made to keep the 
editor simple (from the user's point of view). Of secondary 
importance was machine and system, i rdependerce , and portability 
of the implementations. The resultant specifications are 
described informally (from the point of vi“w of the user) below. 

The constraints upon terminals and line speed<^ , coupled 
with the restricted nature of the editor led us tc select a 
"line oriented editor" approach. >ith the addition of a logical 
line terminator character and a sim.ple display fun^'tion, line 
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oriented editors have been shown to function efficiently with a 
variety of terminals using a wide range of line speeds in a time 
sharing environment (4), (5). 

A minimum set of commands consistent with easy use has been 
selected (5), (6). These commands draw their mnemonic symbols 
from the first letters of their key words taken in normal 
Fnglish language order. For example, the command to "insert text 
<A>fter <L>ine 5" is "aI 5". There was some desire to limit the 
mnemonics to single characters. While this would decrease the 
total number of key strokes required in an edit session, the 
decrease is a small percentage of the total number of characters 
typed. The advantages of natural English language command 
ordering combined with the relative independence from many other 
editors which use single character commands (hence decreasing 
the chances of confusion and error for persons inadvertently 
reverting to other editor commands) was considered to outweigh 
the advantages of exclusive use of single character mnemonics. 

There are a total of eleven commands, only seven of which 
need be used to obtain full text editing capability. These 
eleven commands can be rougnly subdivided into five basic 
groups : 

1. Line Insertion and Peplacemert commands (two commands) 

2. String Replacement commands (one basic command) 

3. String Search commands (one basic command ) 

4. Terminal Output commends (four commands) 

5. Control commands (three commands) 

These commiends are more fully described in Table 1. 
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Since many of the prospective SLED users are only 
occasional users of computer systems, initiation of all 
implementations should be uniformly commenoed by typing only 
’*SLED<Carrage-return ">" after linking and logging into the 
network host machine. At this point, the casual user may ask for 
a menu to refresh his memory as to the basic commands and their 
format via the "l^" command. (See Figure 1 for an example of the 
<M>enu output.) The possibility of SLED users equippeo with low 
speed terminals or low speed lines requires that this message be 
kept brief. Two incorrectly formatted requests in series will 
automatically cause the execution of a <'^>enu cormard. 

A more experienced user may directly execute th® <V>®rsicn 
command which will print a brief version identi f i<^a ti on , the 
name and telephone numbers of consultants who can provide some 
help if required, and will explicitly identify any features of 
the editor which are required by the local system. A sample of 
the <V>ersion output is shown in Fieure 2. 

The editor, like many other editors, features essentially 
two modes: "Edit command” mode and ”t®xt Insert” rode. SLEE, 
when initialized, starts in "Fdit <'ommand” mode, and requests an 
edit command from the user's console by transmitting to the user 
the prompt "F>". This prompt will also be transmitted following 
the successful execution of any edit cor-mand message line 
(except one containing the ”<'0>uit” command) and the editor will 
await further instructions. Following this prorpt the user can 
enter any command shown in Table l. Co’^mands and thei^ fields 
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can be separated by any valid logical message terminator (see 
Figure 2). The character "Carriage return" always serves as a 
message terminator. One other character is provided for use as a 
message terminator, and this is chengible at the direction of 
the user via the <C>hange <T'>ermina tor command. This feature 
allows the "stacking" of editor commands within a single 
physical line of input. This feature is demonstrated below, and 
is extremely convenient in a network operating environment. If 
the command executed by the user causes the editor to enter the 
"text Insert" mode, the editor will prompt the user for data 
with the symbol "l>". All text entered after these prompts will 
be copied directly to the text file, and will not be interpreted 
as edit commands. The only way to return from the "text Insert” 
mode to the "Edit command" mode is by entering a single message 
consisting of ONLY a period 

V’hlle these two prompts are somewhat inconvenient to users 
desiring to operate in a "non-echo" mode, they are, in general, 
necessary for two reasons. They are useful in confirming to the 
(Inexperienced) user which mode he is currently in? and they are 
vital in systems which do not save data buffers as a 
synchronization mechanism (for example a PDP-11 using the PSX-11 
operating system which does NOT allow "type ahead" of logical 
read c ommand s ) . 

These modes and their functions can he better understood 
from the following example of SLED usage: 
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EXAMPLE 1: USING SLED TO CREATE A PILE 
(Fror a UNIX Like implementation) 

'TSLED 

E>0 

f ilename?>NEW.f lie 
-creating file "NEW.flle"- 
E>AL0 

l'> First text line 
I>Second text line 
I> Third text line 
I>. 

F>L1,3 

1 First text line 

2 Second text line 

3 Third text line 
F>Q 

% 

In the above example, the SLEF editor was used to create a 

new text file, and to enter tnree sirpl^ lin<=s of text. Use of 

the logical message terminator key ^if availatle) can 

signlf icantly simplify the use of the editor. This key allows 

several command lines (either edit commands or insert lines) tc 

be entered on a single physical line from the terminal. Fxam-ple 

2 shows the use of the logical message terminator key («^hown as 

"$”) to "stack" several editor commands into a single line of 

input. The effect of the commands shown in this example are the 

same as those shown in Example 1. 

F/AMPLE 2; TFF LOGICAL MESSAGE TEEMINATOF 
(Same effect as Exa'^ple 1) 



%SLEE 

E'>O^NEW.file$ALO 
-creating file "NEk . f i le’’- 
I> First text line$Second text line 
I> Third text line$. $L1 ,3iC 

1 First text line 

2 Second text lice 

3 Third text line 

0 / 

/J 
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Note that in the fifth line of the above example, a line of 
text was inserted, and then the insert mode was termiinated (by- 
sending a message consisting of only a delimited by the 
logical message terminator) and "Edit mode" commands were then 
sent. It is this power of transmitting multiple messages 
delimited by a reserved key which allows those users with slow 
terminals or those experiencing long data transmission delays 
over the network circuits to effectively use the editor. 

Vany persons considering the editor instruction set in 
Table 1 ask how it is possible to delete lines and patterns with 
this editor. These functions are acomplished with the use cf the 
"replace" functions, replacing the items to be deleted with 
"nothing". In the context of this editor, a "strirg" consists of 
a sequence of characters which does not contain any of the 
logical message terminators. Thus, a string is a portion of a 
line since all lines terminate with a <RETURN> which is a 
terminator. To replace portions of lines one uses the <R>eplace 
<S>tring command, while the <R>eplace <L>ine command is used for 
larger modifications. For example, consider the file created in 
Example 2: supppose we wanted to delete the string "text" in the 
first line, and delete the entire third line. Using the "rs" and 
"RL" commands this could be accomplished as shown in Example ?. 
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EXAMPLE 3: DELETING STRINGS AND LINES 



%SLED 

E>0$NEW.file 

- 3 lines in file "NEW .f i le"- 
E>L1 

1 First text line 
E>RS$teit$$Ll 
1 First line 
E>RL3$.$S1 

1 First line 

2 Second text line 
E>Q 

% 



In the above exatnple, the pattern to be deleted in line 
number one was replaced with a string’ consisting of no 

characters. The third line was deleted by replacing’ it with a 
null line (ie. entering INSFRT mode, and exiting -via a messae^'e 
consisting of only a period- without entering any data). In mu^h 
the same manner the desire to insert text "Before Line n" can be 
accomplished with commands to insert text "A^ter Line r-l". 

SLED implementations must also cushion the user from, his 
mistakes (ie. provide "fail soft" features). For example, an 
attempt to open a non existant file should orodu'^e an error 
message as shown in Example 4. 

EXAMPLE 4; Soft Failure 

%SLFD 

S>L1 

-no text file open- 
E>O^NEW.f ile 

2 lines ir file "NEW. file" 

E>0 

% 

In addition to the normal demands of defensive pr ogra'’"min g. 
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the nature of the editor requires that careful attention he paid 
to error detection and recovery. The variety of terrlnal types 
and line speeds requires that the SLED messages he both clear 
and concise. The niinimum set of SLED advisory messages is shovn 
in Table 2, along with the circumstances which will cause them 
to be generated. Ml implementations must detect these 
situations and recover gracefully. Individual implementations 
are encouraged to perform more sophisticated consistency checks 
for abnormal user and system conditions. 

CONCLUS IONS 

Significant increases in the productivity of computing 
professionals can be realized if we can make our existing 
computer resources more ’’usabl“". The ultimate goal -the 
creation of an effective and uniform man/computer interface- is 
perhaps idealistic and unachievable. There are however, a number 
of areas where we can achieve success, and make more efficient 
usage of our human and machine resources. One such area is 
uniformity of software development tools in distributed 
computing systems. 

The Standard Line EDitor project is an experiment in this 
vein. Several testbed implementations of S^EE are now being 
written. With the completion of these nrogra.rs, and with the 
continued support of the Navy Laboratory Computer Committee and 
the NLCC Software Technoloe'y Working Group, it is hoped that 
SLED may be implemented throughout the NALCON. This will be a 
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first, srrall, experimental step along the pathway to 
effective and uniform software development tools 
computer network envi ronmients . 



develop! r.s 
for use in 
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Table 1 : 



SLED Command Summary 



COMKAMD FUNCTION 



USAGE 



LINE INSERTION AND REPLACEMENT COMMANDS: 
insert text After Line number n 
insert text to Replace Lines n thru m 
or., to insert text to Replace a single Line, n 

STRING REPLACEMENT COMMANDS 
Replace all occurrences of String "p” with the 
string "q” in lines n thru m inclusive, 
or.... Replacj^ all occurrences of String "p” 
with string *'q" in line n 
or.... Replace all occurences of String p’ 
with string "q” in the current line. 

STRING SEARCH COMMANDS 
Display all lines containing String "p" 
or... Display all lines between^^l ines n and rt, 
inclusive which contain string ”p' 



ALn 

RLn,r 

PLn 



rSn ,m$p$Q i 
®Sn$p$q$ 



RSip$q$ 



1 3 

DSn ,m "^^pi 



OUTPUT COMMANDS 

set current Line to n and display that line In 

or... display the current line L 

or... display Lines n thru m inclusive, end set In,m 

the current line to m. 

display a "Screen” of lines (23 lines) beginning Sn 
with line n 

or... display a "Screen” beginning with S 

the current line 

display Version and implementation information V 

display <^''>enu of editor commands M 

CONTROL COMMANDS 

Open or Create a file for editing 0 

Cuit the editing session and update all files C 

Change the message Terminal or C'^ 



The symbol indicates the use of a logical message 

terminator, not the <PETURN> key. (See further the text and 
Figxire 2 . ) 

(*) These commends cause the editor to enter the TEXT 
INSERT mode. 
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Figure 1: 

Sample output from <'M>enu command 



SLED COmAND 

LINE/TEXT INSERT 



ALn 


insert <A>fter <L>in 


e n 


PLn 


<R>eplace <LMne n . 


or • 


RLn , m 


lines n thru m 




OUTPUT 


COMMANDS 




L 


display current<L>ine 


Ln 


or line n , 




Ln ,m 


lines n thru m' 




S 


<S>how a "screen" of 


lines 


Sn 


show a screen about 


In #n 


Ml 


show command <'M>enu 


( this ) 


V 


show <V>erslori information 



TO <Q>DIT TEE EDIT TYPE "0<ret>" 



SU^r.AEY 

STRING RFPLACEMFNT 
RS$p*q^ • <^>eplace <^?>trint* 
RSn$p$q^ "p with "q" in 
RSn,nip^q$ inidcated lines. 
STRING SFARCH 

DS$p$ <D>isplay lines wt 

string "p", 

DSn,m$p$ cr show any lines 
n-m containing "p" 
CONTROL con:mands 
0 ^0>per a file or 

create a file for editing 
CT <C>hange the logical 
message <T>ermir.ator 



Figure 2; 

Sample output from <V^e^sion Command 



SLED Version Pasl.l NPS-Mcnterey 600523 
Local Expert Is J. Doe 406-646-2449 0600-1600 FST 

LINE DELETE KEY is <COiJTROL-U> 

CHARACTER DELETE FEY is <RU^0UT> (also called DFLi^TE) 

EDITOR LOGICAL MESSAGE: TERMINATORS ARE: 

(1) <RETURN> and (?) <ESCAPE> (echo? " f' ) 
** the message terminator can NOT be changed tc ’’Line-Feed’ 

Local System supports UPPER/lower case 

Local System DID NOT require deviation fm SLED standard. 
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Table ?; 



SLED 


Minimum Advisory Messages 


Message 


Situatior and Editor response 


-invalid command- 


in command mode an unrecognizable 
command was issued (or an arrbigious 
delimiter was used.) 


-n lines in file ”f"- 


an <0>pen command on file "f" completed 
successfully. 


-creating file ”f”- 


tried to <0>pen file "f ", which did 
not exist. A new file is created. 


-closing file "f"- 


an <0>pen command was issued with_^e _ 
file already open. This file, "f" 
is updated and closed, and the 
command proceeds normally. 


-ro text file open- 


an edit command was executed without 
a text file open. 


-no string found- 


a "RS" or "DS” command was issued, 
end the s'=>erch string was not 
f cund , 


old string?^ 


(a prompt) A "RS" or ”DS" command 
was Issued and the first string 
was not specified. The editor now 
waits for the string to be entered 


new string?> 


(K prompt) A ”rs" command was issued 
where the second string was not 
specified. The editor now waits 
for the string to be entered. 


file name?> 


(A prompt) An <0>pen command was 
issued without specifying the name 
of the file. The editor now 
waits for the file name to be 
entered . 


term! nator?> 


(A prompt) A <C>hange <'’">ermi ra tor comman 
was issued. / valid ASCII character is 
entered to act as a message terminator. 
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